A typical computer-aided design ("CAD") system employed in engineering contexts uses a geometry-oriented approach to define and represent engineering information. The data is generally stored in a large set of geometrically organized files with links to external non-graphical data. The format and content of the files are predefined by the CAD system, with all of the data types known to the system compiled into the program.
Such an approach has the advantage of uniformity and predictability between system users from different engineering domains. In a system implemented with great attention to hardware and version compatibility, data files created with one version of the CAD system can be viewed by other versions of the same CAD system regardless of hardware platform. The approach works well for creating 2D drawings and 3D models of the physical properties of a design, but lacks the sophistication and flexibility to maintain the structure, topology, and additional attributes or descriptive information that accompany a complete engineering model. Furthermore, multi-platform and multi-version software support is a serious burden for both the original producer of the CAD system and for others that add customized extensions.
To properly model a complex design, engineering or otherwise, a computerized modeling system ("CMS") must represent not just the geometric properties of a model, but also the domain-specific relationships between components in the design and tacit information about the model that arises during the development of the model. However, the most efficient strategy for organizing and storing model information does not always correlate with the geometric properties of the information.
Further, since the data types expressed in an engineering model vary widely between engineering domains (electrical, mechanical, fluids, e.g.), it is not practical to express all of the possible combinations of data types within the program that operates the CMS. Moreover, since model data from differing domains may be simultaneously required in arbitrary combinations by a user, multiple, unrelated domain-specific tools cannot be employed.
CMS Requirements
A CMS must solve the problem described above by providing flexible programming tools that allow a software developer having engineering domain-specific expertise to develop programs and data structures ("schemas") relevant to any such domain. A user of the CMS employs one or more such schemas, whereby representations of domain-specific components ("objects") derived from the schemas can be combined and integrated in arbitrary combinations in connection with a single project.
To accomplish such a goal, the CMS must address the following concerns:
Data portability and longevity--In large organizations, engineering groups often work on multiple different types of mixed hardware and operating system configurations ("platforms"). Moreover, the life cycles of a larger project will often exceed the lifetime of one or more of such platforms. Accordingly, it is essential that CMS data that originates on one platform be useable on any other platform without translation. As a result, the CMS does not constrain an otherwise natural progression to the most cost effective computer systems. Furthermore, a project defined by such CMS data can be archived and reactivated years later on a new platform without any loss of fidelity.
Similarly, the type and meaning of the information in a project can change dramatically throughout the project life cycle. For example, data for a particular component may change several times during the project life cycle, usually because the manufacturer of the component modified the component or replaced the component with a similar or related component. It must therefore be possible to refine and revise the schemas that are used by the project (i.e. allow "schema evolution") without jeopardizing the integrity of the already-existing CMS data.
Data integrity--A CMS stores a tremendous amount of valuable information. However, the value of the information can only be secure if models created by the program are accurate, reliable, and accessible. To ensure the data in a CMS model maintains internal consistency, it is necessary that such data always be accessed and modified by the same schemas that defined and created such data. It is therefore essential that such schemas be easily accessed and ubiquitous with respect to the CMS model. Moreover a CMS must minimize the need to produce and distribute copies of CMS models. As should be evident, when multiple copies of the same model exist, any individual copy stands a greater chance of being rendered partially or wholly obsolete.
Large data sets--The size of a typical CMS model can be quite large, on the order of several hundred megabytes. The CMS must handle such large models efficiently. Further, the amount of information in a model cannot be limited in a preset manner.
Many simultaneous users--CMS models are typically shared simultaneously by many users within an organization. Some users require access for inspecting and querying only, but others need access to add to or modify the model. Accordingly, the CMS must ensure that changes to the model are properly coordinated and that the model is kept in a consistent state at all times.
Many simultaneous schemas--Engineering projects typically involve collaboration among several engineering disciplines, each being represented by one or more CMS schemas. A CMS is expected to facilitate the integration of the information created by each discipline to allow easy and consistent access by users in the other disciplines. Therefore, a CMS must store and manipulate information defined by multiple schemas simultaneously. Further, it must be possible for one schema to reference information defined in and maintained by another schema within the project and that reference must be kept consistent throughout the project life cycle.
Flexibility and Extensibility--A CMS is typically refined by a developer based on the domain that the developer is directed toward. Additionally, a CMS is refined by the end user to include user-defined restrictions and extensions. Since every user has different requirements, the ability to extend and customize the system "in the field" is essential.
Performance--Engineering models in particular are characterized by large data sets, yet users demand near-instantaneous response times. A CMS must therefore be able to organize and store data such that access time to the data is optimized.
Ease of Use--A CMS user is presumed to be an expert in his domain. However, he is not necessarily a sophisticated computer user and is likely not willing to invest valuable time in extensive training. Furthermore, since multiple users from different domains will employ the same CMS, the domain-specific expertise of the users will vary widely from session to session. Accordingly, use of a CMS must be simple, intuitive, and familiar, and the schemas employed by a CMS must be flexible enough to allow access to schema data at various levels of detail and complexity depending on the user.
CMS Implementation
Given the foregoing CMS requirements, a successful CMS must incorporate a robust environment for programmers to implement schemas, and an easy-to-use environment for users to employ those schemas on real world problems. To that end, the CMS implementation must include:
Schema Environment--Schemas must contain all necessary information to display, manipulate, query, revise, and interpret a model; there can not be any application-specific expertise built into the CMS itself. Schemas must be portable so that they can execute on any platform that the CMS can execute, be inseparable from the project model, be flexible and expandable without requiring the original schema source code for recompilation, and execute efficiently. Due to the large quantity of information modeled by a CMS, the routines that process such information must do so in an efficient manner. Schemas must also be able to evolve over time such that they can be revised and extended as new requirements arise.
Application Framework--The geometric tools (location, manipulation, creation, display, visualization, vector algebra, etc.) for manipulating schema objects must be presented to the user in a familiar and easy-to-use environment, or "application framework". The user interface programs must be portable across all platforms on which the CMS runs so that users can choose among appropriate platforms. However, the application framework itself must interact with the native Operating System or Graphical User environment on which the framework executes. Such interaction must be transparent to the user.
In certain cases, special support must be added to the application framework to take advantage of advanced capabilities of certain platforms. Wherever possible, the capabilities of these advanced systems should be emulated on lesser platforms.
Change Propagation--When an object in a model is modified, other objects in the model may change as a result. A CMS must express relationships between objects such that the need for effecting changes to objects "downstream" may be recognized, propagated, and executed. In addition, if such propagation results in an invalid or inconsistent state of the model, the entire change must be reversed.
Model Persistence--State information for objects in a model must be maintained across editing sessions. Accordingly, the objects must be dynamically reinstated each time the CMS is used to view or manipulate the model.
Project and Model Management--A CMS must maintain the integrity of a model. Accordingly, mechanisms are required to: lock portions of the model to regulate multi-user access; control revision access; create and manage parallel development to the same model; merge changes from multiple users on the same model; permanently identify specific versions of constituent models of a project as contributing to a particular state of the project; and regulate access to the database according to graduated security levels.
Distributed Components--To help prevent data obsolescence, a CMS must allow for having portions of the model distributed out to those parts of an organization (or remote vendor locations, subcontractors, etc.) where they are most easily maintained. At the same time, a "live connection" to the distributed portion must be maintained in each model where it is referenced.
The present invention comprises a computerized modeling system ("CMS") that electronically models engineering information for design, analysis, manipulation, simulation, visualization, integration, decomposition, storage and retrieval. The present invention is highly suited for engineering environments such as mechanical engineering; structural engineering; electrical engineering; civil and roadway engineering; plant design, layout, and operation; building engineering and construction; facilities planning and maintenance; mapping; and geo-engineering; among other things.
To address the requirements discussed above, the preferred embodiment of the present invention includes an object-oriented schema implementation programming language, a compiler, a linker, and a run-time system. The programming language is largely based on the C and C++ programming languages with certain CMS extensions as will be described below, and is employed to write schema programs that are compiled using the compiler. The output of the compiler is an object file. The linker combines a group of object files into an executable program that is portable across many platforms, where each platform has a run-time environment tailored to that platform. Each program may also be a shared library. If so, the program exports references to classes, functions, and variables. Other programs can have references to these classes, functions, and variables resolved at run-time. A program may both import and export references. That is, the program may use other shared libraries and may serve as a shared library for other clients. A schema may comprise a set of such programs. The present invention includes schemas for general-purpose geometric modeling as well as schema for interfacing to industry standard exchange formats such as "MicroStation DGN", "AutoCad DWG", and "STEP".
The schema programs model information relevant to a predetermined domain. Such domains include engineering domains and other domains. The "schemas" represented by the schema programs include multiple "classes", each of which defines a type of component that may be placed in a model. "Objects" or "instances" are created or "instantiated" from each class, where each object is placed in the model and represents the occurrence of a component for a specific purpose in the model. Each class includes a specification of the data ("variables") held by each instance of the class, plus the program code ("methods") that may be employed to manipulate such variables.
The objects in a model are stored in one or more repositories or "stores". Related stores are logically grouped into a "project" which generally corresponds to a physical project (engineering or otherwise) in the real world. Projects are managed as a single unit by the CMS and are stored in a "project database", generally on a networked server, so that concurrent access can be granted to multiple users of the project.
To initiate a user session, a user executes a query of the project database to extract a subset of the project (i.e. a number of related objects) from the project database into a local database. Since the format of the objects in the project database and in the local database is not necessarily the same, translation may be necessary. The extraction is considered a long-term transaction to the project database such that during the user session no further interaction with the project database is required. If changes or additions are made to the extracted model objects during an editing session, such changes and additions may be posted to the project database at the end of the user session, at which time conflicts that have occurred due to changes by other users are resolved.
Since objects in a project database are defined and interpreted by the combination of instance data and class methods, instance data cannot be interpreted without the corresponding schema. Accordingly, to maintain the integrity of the project data, it must never be possible to encounter an instance without the corresponding schema.
For this reason, the CMS of the present invention treats not just the geometry but also the programs that comprise a schema as components of the project database, as with the instance data. Accordingly, whenever an instance of a class is created in a project database, the schema of the created instance is also copied into the database. Thus, whenever instances of that class are encountered in future sessions, the schema is loaded into memory from the project database.
A benefit of an object-based CMS is that information may be shared with other object-based programs by publishing appropriate interfaces. There are several standards proposed for the mechanism by which objects make requests and receive responses from interfaces of other objects. Two such standards are the Common Object Request Broker Architecture (CORBA) proposed by a vendor consortia including Hewlett-Packard Corporation, IBM Corporation, and others, and Component Object Model (COM) from Microsoft Corporation.